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ABSTRACT 


This thesis explores the use of an artificial physics framework to provide centralized con¬ 
trol of a collection of agents in close proximity to a human operator. Based on the spa¬ 
tial separation between agents, agents to way-point, and agents to operator, the artificial 
physics framework calculates virtual forces that are summed and translated into velocity 
commands. The virtual forces are modeled after real physical forces such as gravitational 
and Coulomb, forces but are not restricted to them, for example, the force magnitude may 
not be proportional to one divided by separation distance squared. These virtual forces 
allow the collection of agents, or the swarm, to autonomously find the operator, create a 
formation, and navigate way-points. The operator has high-level control of the agents via 
a hand held-controller. This framework is applicable to a scenario where an operator in the 
field needs to work with several autonomous vehicles but is unable to devote a high-level 
of focus to controlling agent behavior. We implemented an artificial physics framework 
in two simulation environments and in physical indoor experiments with a team of three 
unmanned aerial vehicles. The results from the physical experiments show that an artificial 
physics-based framework is an effective way to allow multiple agents to follow a human 
operator inside a small arena with only minimal operator input. 
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CHAPTER 1: 
Introduction 


1.1 Motivation 

The role of unmanned aerial vehicles in warfare continues to increase as the cost and tech¬ 
nical burdens associated with these platforms decrease. According to Gertler’s 2012 U.S. 
Unmanned Aerial Systems report to Congress [1], the Department of Defense (DOD) un¬ 
manned aircraft inventory from 2002 to 2010 increased by more than a factor of 40. Current 
DOD unmanned aerial vehicle (UAV) programs of record are mainly focused on procuring 
highly equipped platforms adapted to support many different mission sets. This approach 
has led to serious cost concerns for programs that were once considered low-cost replace¬ 
ments for their manned counterparts [1]. 

Outside of the military, the last decade has seen a drastic rise in the number of commercially 
available unmanned systems to perform tasks ranging from underwater weld inspection to 
home cleaning. One very interesting civil development in this field is the rise of the UAV 
home hobbyist. Now, for as little as a few hundred dollars, someone with basic electronics 
and programming knowledge can adapt a “toy” UAV, such as the Parrot AR.Drone, to per¬ 
form sophisticated tasks like flying way points, video surveillance, and object avoidance. 
Hobbyists and researchers are able to tap into vast amounts of open source code, algo¬ 
rithms, and applications that make customizing UAV behavior even easier. Through the 
internet, many disparate universities, research labs, and individuals can easily collaborate 
“crowd-source” solutions to complicated UAV problems. 

A potential alternative to the Department of Defense’s high-cost, high-capability UAV strat¬ 
egy is to focus on developing large numbers of low-cost, low-capability platforms that op¬ 
erate in theater simultaneously and cooperatively. These platforms would be able to self 
organize into a swarm, communicate, and navigate with a high degree of autonomy. Each 
individual within the swarm can operate based on a simple rule set. When these individuals 
interact with each other, complicated collective behaviors can arise. In nature, ant colonies 
are a prime example of this. Although each ant appears to be operating on its own, the 
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ant colony as a whole is highly organized [2]. In the study of swarm systems, the terms 
organization and emergenee are used to deseribe the nature of the collective behavior. “Or¬ 
ganization” refers to the inerease in order or structure of the eolleetive, and “emergenee” 
is when new eolleetive behaviors, patterns, or properties arise as a result of interaetions 
between individuals [3]. If one or several platforms malfunetioned or were lost, the swarm 
would reorganize and earry on the mission. Swarm behavior could be controlled by a 
human operator or a small team of operators at a distant base station or while embedded 
among the UAV on mission. 

1.2 Objectives 

There is a resurgenee of swarm behavior research due to advances in vehiele navigation, 
communications, and processing abilities. For individual platforms to funetion together as 
a eohesive swarm, a framework for sharing information must be established for platforms 
to aet on this information in support of mission goals. This framework is ideally sealable 
to allow for eoordination between few or many UAVs and compatible with many different 
types of unmanned vehieles. 

Beeause it is unlikely, at least in the near future, that large swarms will be operating eom- 
pletely autonomously, it is important to determine the most effeetive way for human opera¬ 
tors to eontrol swarm behavior and reeeive information about the environment. One goal of 
this area of researeh is to balanee vehicle autonomy with the amount of required operator 
input. The benefits of maximizing autonomy inelude: 

• Redueed required number of operators 

• Minimized operator fatigue 

• Quicker response times to environmental stimuli 

Some possible problems with increased autonomy are reduced fault tolerance, the inability 
to plan for all variables encountered in the environment, and inability to adapt or ereate 
new behavior patterns as the problem ehanges. 

This thesis addresses the problem operator-UAV interaetion in the field with many quadro- 
tors. In addition to simulation data, experimental data was eollected in a controlled physieal 
environment. The seenario approximates a soldier on patrol in a hostile environment who 
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is attempting to detect and localize threats. One goal is to design and implement an in¬ 
tegrated system so that the UAVs take off as a group and self-organize into a formation 
around the user. As the operator moves through the environment, the drones dynamically 
maintain proper distance from the operator and each other. During the evolution the drones 
will actively scan the area for threats using the onboard sensors. If a threat is detected, the 
swarm will alert the user via a hand-held device. 

1.2.1 Simulation 

Simulation is a popular method for testing frameworks and examining swarm behavior. 
This method allows the researcher to make small changes to algorithms and rule sets and 
immediately collect data on swarm behavior. More importantly, this allows the tester to 
bypass all the logistical details associated with actually operating robots in a physical en¬ 
vironment such as charging batteries, establishing communications links, and positioning 
vehicles. Despite the advantages of simulation, testing in a physical environment is re¬ 
quired to validate rule sets and observe how the vehicles react to variables not considered 
in the simulation. This thesis uses simulation to test the artificial physics framework prior 
to implementing the designed framework on physical robots. 

1.2.2 Human Swarm Robot Interaction 

Determining the most efficient way for an operator to control a swarm of UAVs is a subset 
of swarm UAV research that is still in its infancy. One must consider how much autonomy 
the vehicles should have versus how much user interaction is required. Minimizing the 
amount of required operator interaction reduces the number of necessary personnel and 
allows the operator to focus on other facets of the mission. This thesis attempts to advance 
the area of human swarm robot interaction (HSRI) by allowing the operator to control 
some aspects of swarm behavior using a hand-held controller while standing among the 
agents. Part of our study is to create an algorithm that allows several drones to find a 
human operator and create a formation around him or her with little or no input given by 
the operator, see Figure 1.1. 

1.2.3 Questions 

Some research questions explored in this thesis include: 
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Figure 1.1: One goal of our research is to allow a group of UAVs to autonomosly create a 
formation around a human operator. 

1. What rule sets must be employed to allow the swarm to form a formation, move, and 
avoid obstaeles while not colliding with the operator or fellow vehicles? 

2. What is the most efficient way for an operator to control swarm behavior in the field? 

3. How will the swarm provide the user with information about the environment? 

1.3 Benefits of the Study 

This study provides insight into a proposed efficient method to balance UAV autonomy 
and operator interaction while in the field. The framework used in this experiment could 
be extended to UAVs operating in the outdoors using global positioning system data for 
position in lieu of a motion capture camera system. It also paves the way for creating al¬ 
gorithms to allow for more complicated behavioral control of the swarm such as directing 
an attack or having the swarm perform tactical reconnaissance on the path ahead. Coor¬ 
dinated swarms of conventional off-the-shelf quadrotor UAVs could be a powerful force 
multiplier in the expeditionary sensor grid while being much more cost-effective than ex¬ 
isting high-end UAV programs of record. Although data taken from a single unit may be 
inconsequential, when aggregated with data from many other swarm members, a higher 
level of battlespace awareness is achievable. In summary, this study helps to understand 
the link between micro agent level behavior to macro behavior of the entire swarm while 
in the presence of human operators. 

1.4 Thesis Organization 

The next chapter reviews similar work on swarm robot control while highlighting some of 
the frameworks used to control multiple robots simultaneously. Chapter 2 also introduces 
physicomimetics or artificial physics (AP) on which the robot control framework developed 
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in this thesis is based. In Chapter 3, the various systems that make up the experimental 
design and their integration are discussed. Chapter 4 presents results and analysis from 
several experimental scenarios. Conclusions, recommendations, and future work are in 
Chapter 5. Bold font is used to represent vector notation, and hatted vectors denote unit 
vectors. 
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CHAPTER 2: 
Related Work 


The focus of this thesis is to explore the concept of an operator controlling many au¬ 
tonomous UAVs while physically located among them. These UAVs need to operate in a 
framework that is scalable, fault-tolerant, and inexpensive while demanding minimal direct 
control by the human operator. Over the past several decades, many different frameworks 
have been explored using simulation and physical experimentation. 

Typically, robot swarm behavior is based on interactions between each member of the 
swarm and each member and its environment [4]. In swarm robotics literature, the words 
“microscopic” and “macroscopic” are used to differentiate agent level and swarm level 
behavior, respectively [5]-[7]. At the microscopic level, robots have limited knowledge 
through their sensors about the world around them. Nominally, at this level, changes in the 
perceived environment elicit very simple responses, e.g., if my left bump sensor detects a 
collision, turn right. At the macroscopic level, swarms can exhibit behaviors such as explo¬ 
ration, foraging, and flocking. Linking micro to macro behavior is the main task of swarm 
robotics. 


2.1 Potential Field Method 

One way to control robot behavior at the micro level is with a potential field method (PFM). 
Using artificial attractive and repulsive potentials to control unmanned vehicles in a swarm 
is not a new concept. This approach was initially applied to control a manipulator arm in a 
fixed environment with several obstacles [8]. The manipulator is repulsed by obstacles and 
attracted to targets. A simple algorithm calculates the potential energy function, U{x,y), 
based on the separation distances to environmental boundaries, obstacles, and the target. 
Because force is proportional to the gradient of the potential energy function. Equation 2.1 
allows us to calculate the force vector. 

F(x,y,z) =-V[/(jc,y,z) (2.1) 
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The forces vector is converted to a desired change in velocity by Equation 2.2 where At is 
the amount time per update cycle and m is the virtual mass of the robot. 


F(x,y,z)At 

m 


( 2 . 2 ) 


After this calculation, Av is converted to a control signal to the robot’s motors. This allows 
for basic path planning by choosing the path with the steepest gradient ultimately leading 
to a the position where potential energy is minimized. This simple, but elegant framework, 
now known as the PFM, is applied to many different problem sets because it is quick to 
implement and usually yields acceptable results [9]. Figure 2.1 depicts a typical potential 
field scheme for navigating a robot towards a target way point. 


3D Mesh plot of Attractive Potential Field 



Figure 2.1: A potential field created by an attractive target, from [10]. The agent is programmed 
to move in the direction with the greatest drop in potential energy until it reaches the target 
which has the lowest potential energy. 

2.1.1 Problems with PFM 

PFM is not perfect; there are at least four problem areas as discussed by Koren et al. [9]. 
The first, and the most referenced trouble area, is the creation of trap situations due to local 
minima in the potential field [8]. This problem arises when the robot finds itself in a dead¬ 
end, which can easily arise by nearing, e.g., a U-shaped obstacles or environment boundary. 
One possible remedy to this issue is global path planning [11]. Global path planning allows 
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the robot to identify that it is in a potential well trap and determine the best route to eseape 
the trap and eontinue towards the goal. A seeond limitation is the frequent inability to 
travel between two obstacles even though they have sufficient physical separation that the 
robot should be able to pass through. This limitation can make it difficult for unmanned 
vehicles to travel through doorways or enter hallways. A solution to this problem is to 
carefully tune the relative magnitudes of the target and obstacle forces. A third limitation is 
oscillations in the presence of obstacles. Unstable motion can result as the vehicle travels 
alongside an obstacle, especially if there is a discontinuity in an otherwise smooth surface. 
A fourth problem is unstable oscillations while traversing a narrow corridor. While in a 
narrow corridor, the robot is repulsed by both sides. If the robot detects a discontinuity 
in the corridor, frequently the vehicle will start oscillating rapidly and eventually have a 
collision. 

2.1.2 Examples of Swarm Robot Experimentation using PEM 

Multiple research groups successfully use PFM-based frameworks to control groups of 
robots. For example, Barnes et al. created a framework for both simulation and physical 
experiment involving groups of four and ten robots involved in a convoy protection scenario 
[12]. This approach used potential fields calculated using distance from the convoy vehicle, 
distances between robots, and a minimal number of weighting parameters. This method for 
multi-robot has commonly been used in robotics competitions such as the RoboCup Robot 
Soccer League [13], [14]. As discussed in [13], potential fields are calculated based on 
the layout of the playing field and the objects in the field. These fields determine the 
destinations and actions of each of the robot soccer players. 

2.2 Physicomimetics 

A physicomimetics, aslo known as AP, based framework can be used to control behavior 
for a whole swarm of unmanned vehicles. This framework is one of several varieties of 
PFM-related approaches. Physicomimetics introduces artificial forces that are converted 
to velocity commands for unmanned vehicles. The forces are usually calculated based 
on a robots distance from other robots, obstacles, and way points. Artificial forces are 
calculated at run-time vice calculating potential fields in advance, then later converting the 
fields into forces. Figure 2.2 shows how the physicomimetics framework comprises the 
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outer control loop, which feeds velocity commands to the inner robot control loop, which 
translates these commands into motor and servo actuation. When this framework is applied 
to multiple vehicles, the robot group can self-create a formation in a similar fashion to how 
intra-molecular forces cause a crystal lattice to form [15]. The formation that the vehicles 
form will nominally be the one with the lowest potential energy. An additional friction 
force is usually added for stability. The mathematical basis for physicomimetis or AP is 
given in Chapter 3. 

Physicometics is a widely implemented framework because of its adaptability and intuitive 
approach. In [16], artificial forces are based on solid, liquid, and gas particle interactions, 
which translate to different types of swarm behavior. Although usually applied to holo- 
nomic vehicles, physicometics is also useful for controlling nonholonomic vehicles such 
as fixed wing aircraft [17]. This is accomplished by adding nonlinear constraints, such as 
treating the agent as a collection of particles vice a single particle and adding the concept of 
torque. This approach was tested in a fixed wing swarm UAV plume detection simulation 
in [18] with favorable results. Apker et al. went on to test a physicometics-based frame¬ 
work in a four-robot auditory scene monitoring scenario [19]. In his experiments, Apker et 
al. uses the four-wheeled Pioneer3-AT ground robot, which requires modifications to the 
artificial physics algorithm to account for the platform being a very poor approximation of 
a point particle. In [19], four robots traverse a cluttered environment and autonomously 
create a diamond formation once at an attractive goal way point. 



Figure 2.2: Relationship between a robot's control system and a physicometics-based framework, 
from [20]. 
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There are many challenges for taking a physicometics implementation that works in sim¬ 
ulation and applying it to physical unmanned systems. Apker and Potter [20] give several 
recommendations for making this transition. 

2.3 Human Swarm Robot Interaction 

HSRI is a previously neglected, but now fast-growing, facet of swarm research. For swarms 
of fairly unsophisticated robots to exhibit sophisticated group behavior, a human operator 
needs to inject guidance and extract information from the swarm [21]. The operator needs 
to be able to insert domain knowledge without needing to control individual robots. In [21], 
the operator controls the swarm by taking control of an individual robot or small groups of 
robots. The user directs the individual or small group towards an objective and the swarm 
follows on their own. Ideally, this is accomplished through an intuitive interface, such as a 
hand-held controller vice a keyboard and mouse. 

Another way to control swarm behavior is to have the operator physically located among 
the vehicles in the swarm. The vehicles are both attracted and repulsed by the human and 
maintain a formation around him or her. This approach was applied to a firefighter search 
and rescue simulation in [22] and was named the social potential field method. Although 
the study did not involve real robots or human operators, it demonstrated that the social 
potential field method is an effective way to develop formations, avoid obstacles, navigate, 
and respond to the failure of individual vehicles. 

2.4 Swarm Robot Platforms 

2.4.1 Fixed Wing UAVs 

Fixed wing UAVs are nonholonomic, and due to logistical and field testing constraints are 
typically employed less frequently in multi-robot research. The University of Pennsylva¬ 
nia GRASP Lab has successfully flown two fixed wing UAVs in a leader-follower way 
point following scenario [23]. Massachusetts Institute of Technology uses multiple fixed 
wing gasoline powered UAVs built entirely from commercial-off-the-shelf (COTS) com¬ 
ponents to test group control algorithms [24]. Stanford University’s Dragonfly Project uses 
a ground command station (GCS) developed by Boeing to test cooperative algorithms on 
two fixed wing UAVs [25]. Internationally, research groups such as University of Sydny’s 
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Australian Centre for Field Robotics and the University of Porto’s Apollo project also focus 
on multiple fixed wing UAV research [26] and [27]. Chung et al. at Naval Postgraduate 
School (NPS) [28] set the goal to have 50 unmanned fixed wing UAVs fight 50 other fixed 
wing UAVs in an outdoor environment by 2015. 

2.4.2 Rotary Wing UAVs 

Swarm research centered around multi-rotor UAVs has increased due to the proliferation 
of relatively cheap hobby- and research-grade platforms [29]. Today, quadrotor UAVs are 
an increasingly common research platforms due to their simplicity and prevalence. One 
major limitation of small rotor-based UAVs is the limited payload and endurance. However, 
addressing the former concern, if multiple UAVs are deployed in a cooperative fashion, it 
is possible to move payloads much greater than any single UAV could handle [30]. Some 
research groups, such as [31], have opted to create their own in-house custom micro UAVs. 
One advantage of this approach is the ability to tailor the hardware and communications 
paths to accomplish specific research goals. Like our research group, others also utilize the 
Parrot AR.Drone for swarm research [32]-[34]. In most cases, the research groups only 
modify or create custom software for the ground control station (GCS) and do not attempt 
to modify the AR.Drone’s firmware which is closed source. 
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CHAPTER 3: 
Experimental Design 


3.1 System Description 

3.1.1 Platform 

We used the Parrot AR.Drone 1.0 as our main researeh platform. The AR.Drone 1.0 as 
shown in Figure 3.1 is a quadrotor UAV with two integrated video eameras. By varying 
the relative speeds of its four blades, the drones moves with six degrees of freedom [35]. 
One 1300mAh after market, 11. IV LiPo powers the drone and gives approximately 13 
minutes of flight time. AR.Drone 1.0 uses mieroeleetromeehanieal systems (MEMs)-based 
inertial measurement units to estimate piteh, roll, and yaw. These measurements are used 
by the on board proeessor for automatie piteh, roll, and yaw stabilization. This automatie 
stabilization makes the AR.Drone piloting very intuitive. Based on simple eommands from 
the user, the drone performs takeoff and landing without any manual eontrol. In the absenee 
of a movement eommand, the drone automatieally trims and hovers in plaee, even in the 
presenee of mild wind. The drone eommunieates with its eontroller via an ad-hoe network 
setup over WiFi. Control software is available for most WiFi-eapable portable deviees sueh 
as the iPad or Android-based mobile deviees. From its ineeption, the AR.Drones were 



Figure 3.1: AR.Drone 1.0, from [36] 


designed to allow third-party developers and hobbyists to ereate eustom software. Parrot 
released a series of software development kits (SDKs), whieh simplifies writing eustom 
applieations for eontrolling the drone from, e.g., a Linux desktop eomputer, Apple iOS 
deviee, or an Android deviee. 
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3.1.2 Robot Operating System 

Robot Operating System (ROS) is an open-source framework for robot applications [37]. It 
functions as middleware software that provides a structured communications layer to allow 
various processes and/or machines with different configurations (e.g., sensors, actuators, 
programming languages) to interact [37]. ROS packages contain nodes which can send 
commands, process sensor information, and communicate with other nodes. For agent 
control, we used the ardrone_autonomy package [38], a ROS driver for the AR.Drone 
that leverages the Parrot SDK. One critical aspect of the project is developing a framework 
for the UAVs to self-organize and move as a coordinated swarm. Our AP based framework 
was implemented as several nodes within a ROS package, described further in Section 3.3. 

Robot Three-Dimensional Visualization Tool (RVIZ) 

RVIZ is a three-dimensional (3D) visualization tool for ROS [39]. Within RVIZ, a user 
can place markers that represent robots or robot components and visualize how algorithms 
behave in a virtual environment before testing in the real world. RVIZ itself does not 
have a physics engine or understanding of how the simulated robots work. However, RVIZ 
works with the ROS tf package, which manages coordinate frame transformations (see Sec¬ 
tion 3.1.4) and is an excellent tool for debugging reference frame dependencies. RVIZ 
shows marker movement in real time, which is useful for heuristically setting gains and 
parameters. 

3.1.3 Indoor Positioning System via Motion Capture Cameras 

We utilized the robot experimentation facilities available in the Naval Postgraduate School’s 
Unmanned Systems Lab, which consists of a high-bay space equipped with a twelve- 
camera Vicon motion capture system [40]. The Vicon system functions similar to how 
a global positioning system (GPS) receiver works outdoors. Using Vicon, we can accu¬ 
rately track objects in a controlled indoor environment. Figure 3.3(a) shows the space 
when viewed from an adjacent stairway while Figure 3.3(b) shows what the Vicon cam¬ 
eras look like. The Vicon coverage area footprint is approximately a 10 by 15 meters (m) 
rectangle. The Vicon system uses near-infrared cameras to track reflective markers with 
sub-millimeter accuracy. To track each individual drone, we affix an unique constellation 
of markers to each drone’s outer shell as shown in Figure 3.4(a). The Vicon system also 
tracks the human operator via a helmet which has its own unique marker constellation, see 
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Figure 3.4(b). The Vieon eameras are eonneeted to a networked reeeiver whieh sends data 
to an attached computer running the Vieon software suite. Vieon software identifies and 
tracks all the unique constellations that are in the Vieon space, see Figure 3.2. 



Figure 3.2: Vieon motion capture software, from [41] 


We used the vicon_bridge package [42] to bring data from the Vieon system into the ROS 
environment. This package publishes translation and orientation data relative to the lab 
reference frame for all tracked objects in the Vieon field of view. Under nominal conditions, 
translation and orientation data streams at 100 Hz. 



(a) AR.Drone with unique marker constellation 
for Vieon identification and tracking, from [41] 


Figure 3.4: Vieon marker constellations 



(b) Operator helmet with unique marker con¬ 
stellation for Vieon identification and tracking 


for object identification and tracking 


15 































(a) View of Vicon Space 


(b) Motion Capture Cameras, from [41] 


Figure 3.3: CAVR Unmanned Systems Vicon Space. 


3.1.4 Reference Frame Management 

Reference frame management is paramount to the success of any framework that attempts 
to provide centralized control to multiple robots simultaneously. The speed at which the 
controlling station can translate between reference frames is also vitally important. In this 
thesis, each drone’s position is referenced to the lab frame through Vicon, but each drone 
has its own internal reference frame to track relative positions to other drones, the human 
operator, and waypoints. The ROS tf package was used for accomplishing this task. This 
package provides a standardized way to track coordinate frames and transformations for an 
entire system of reference frames [43]. Figure 3.5 shows the hierarchy of reference frames. 
ROS tf, greatly simplifies the amount of code required for making calculations between 
the world and agent reference frames and eliminates errors associated with manually coding 
all the reference frame translation matrices. Typically, the tf package takes between three 
and four milliseconds to lookup the transform between two reference frames. 



Figure 3.5: Reference frames tracked by the Vicon system, graph generated by tf 
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3.2 Artificial Physics Algorithm 


We created a AP, or physicomemetics, based framework that ingests position and orienta¬ 
tion information for all agents and outputs velocity commands to all agents based on their 
position relative to each over, way points, and the operator. The first step in this process is 
to turn the Vicon position data into a set of reference frames that the tf package can uti¬ 
lize. This reference frame data is used by a custom artificial physics node which stores the 
translations in a m by n matrix where m is the row index and n is the column index shown in 
Equation 3.1. To further clarify, if m equals one and n equals two, this cell holds the relative 
reference frame information from agent two compared to agent one. Each cell contains a 
quaternion (qm.n) to define a rotation and a translation vector (rni,n) used to translate from 
one local agent reference frame to another where i, j, k, and w are the quaternion basis 
elements and i,y, andz are the 3D unit vectors. The center diagonals are zero because these 
cells link one agents reference frame to its own reference frame. 


Tm.n — 


/ 0 qL2,ri,2 ■■■ qLn,ri,n\ 

q2,l,r2,l 0 ■■■ q2,n,r2,n 

Vqm,l5^ni,l qm,27rin2 0 J 


qm,n — ^m,ni T J 3” Cyn nk -\- 0)m,n 
Tm.n ~ ^m,n^ T ym,ny 3" Zm,nZ 


(3.1) 


Using the translation vectors from Equation 3.1, we calculate the distance, dm,n, between 
each agent in the jc — y plane using Equation 3.2, and store these data in a matrix given by 
Equation 3.3. Similarly, distances between each agent and waypoint as well as between 
each agent and the embedded human operator are calculated and stored. 


m,n — ^ 

J ^m.n 3” 

n 

( ^ 

■■■ 

dl,n^ 

di,! 

0 ■■■ 

dl,!! 

\dm,l 

dm,2 

0 / 


(3.2) 


(3.3) 
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Using the distances stored in the matrix shown in Equation 3.3, Equation 3.4 calculates the 
artificial force, denoted Fagent, felt by agent m due to agent n, where M is the virtual mass 
of each AR.drone, p, and G are constants. We set M to one for all agents, but this number 
could be increased or decreased to give an agent more or less influence over its peers. 
If the separation distance is greater than the desired separation distance. Equation 3.4 is 
multiplied by —1 to make the force attractive. Eigure 3.6 is a graphical representation of 
the virtual force magnitude as a function of distance between agents. Structuring the virtual 
force in this way causes the agents to move towards each other until they reach their desired 
separation distance. At this distance, they begin to repel each other. Overall, this interaction 
causes the agents to maintain the desired separation distance. Using the distances between 
each agent and the operator {dm,op). Equation 3.6 calculates the artificial force (Foperator) 
felt by agent m due to the operator, where p and C are constants, while the distance between 
the drone and operator is less than twice the desired separation distance. If the separation 
distance is greater than the desired separation distance between the operator and the agent. 
Equation 3.5 is multiplied by -1 to make the force attractive, see Equation 3.6. If the 
distance between the operator and the agent is greater than twice the desired separation 
distance. Equation 3.7 is used to calculate Foperator- This decreases the amount of time it 
takes the drones to find the operator if they are initially far away. 

GMM ^ 

Fagent — (3.4) 


operator — 

CM ^ 
id 

where 

dm,op ^ d^jggifed 

(3.5) 

operator = 

-CM ^ 
id 

y^m^op } 

where 

ddesired ^ dm,op ^ ^ddesired 

(3.6) 

operator = 

CMdm,op^m,op 

where 

dm,op ^ '^ddesired 

(3.7) 


Figure 3.7 shows force felt by the agent as a function of separation distance from the op¬ 
erator. The force profile is designed to allow the agent to quickly close distance to the 
operator and maintain the desired separation. Using the distances between each agent and 
the current way point, that is, dm,wp. Equation 3.8 calculates the artificial force, F„aypoint> 
felt by agent m due to the current way point where 5 is a proportionality constant. Unlike 
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Figure 3.6: Virtual force magnitude felt by agent m due to agent n [G = 2.2, p = 2.0), after [15] 


the virtual forces due to the operator and other agents, the force felt due to the way point is 
always attractive. Figure 3.8 is a graphical representation of the virtual force magnitude as 
a function of distance between agent and way point. 


Fwaypoint — B(^dm jwp) Tm, waypoint (3.8) 

In Equation 3.9, the force vectors are summed to give a net resultant force vector. 

n 

Fm.net = Fwaypoint "F Foperator "F ^ Fagent (3.9) 

(=1 

From Fnet we calculate the velocity vector v using Equation 3.10 

Fm.net^^ , /-> 

^m F ym,Q (3.10) 

where At is the amount of time between velocity update cycles and \m,Q is the velocity 

vector from the previous time step. In our algorithm Vm,o is reset to zero each time step. 
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Force Magnitude Felt Between Agent and Operator 



Figure 3.7: This curve describes the force Magnitude felt by the agent due to proximity to the 
human operator (C = 2.2, p = 2.0) 

This effectively turns off Newton’s first law of motion: “An object at rest will remain at rest 
unless acted on by an unbalanced force. An object in motion continues in motion with the 
same speed and in the same direction unless acted upon by an unbalanced force.” In our 
framework, an object or AR.Drone must be subjected to a virtual force to move, otherwise 
it stops. The motivation for this was to keep fast moving drones from leaving the Vicon 
coverage area. The velocity vector is broken into its x, y, and z components which are sent 
to the agents as commands. We set the parameters G, C, and B such that commanded drone 
speed would be below 0.3 meters per second (m/s) based on the size of the arena and the 
maximum separations possible. 

3.3 System Integration 

Running a simple AP experiment involves multiple components working together. Fig¬ 
ure 3.9 shows a simplified system architecture. The Vicon camera system and attached 
computer detect and track objects inside the Vicon space. This information is made avail¬ 
able on a server stack. The controlling station is typically a Linux-based laptop running 
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Force Magnitude Felt Between Agent and Waypoint 



Figure 3.8: This curve describes the force magnitude felt by the agent due to proximity to the 
current way point (B = 2.2). Unlike the other two force magnitude relationships, force magnitude 
due to distance from way point is linear. 

Ubuntu 12.04, ROS version Groovy, and Python version 4.6.3. The eontrolling station runs 
all the ROS nodes for the experiment and eontrols eaeh of the drones through the server’s 
attached wireless router. 

3.3.1 Drone Communication 

Out of the box, the AR.Drones are not designed to have multiple drones connected to 
one controller. To overcome this limitation and to control all the agents from one station, 
NPS researcher Michael Clement [44] created an automated WiFi scanning tool to enable 
telnet access into each detected drone and connect it to a wireless router connected to a 
server under a predefined IP address scheme shown in Table 3.1. By default, the drones 
are set to use the same user datagram protocol (UDP) network ports. This led us to create 
a UDP remapping tool to allow one computer to control all the drones. An explanation of 
how Clement’s multiple AR.Drone communications mapping is available at [44]. Both the 
controlling station and the Vicon system are connected to the drone server via ethemet. This 
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Figure 3.9: Hardware architecture consists of the integration of a Vicon camera system, multiple 
AR.Drones, a wireless network, and a computer functioning as a GCS 


allows the controlling station to send commands to the drones and receive Vicon data using 
one network adapter, as illustrated in Figure 3.9. We created a ROS node called SwarmLoad 
to scan the server for connected drones and attempt to load the ardrone_autonomy driver 
for each drone. We also created a custom graphical user interface to perform group takeoff, 
landing, and emergency reset and to monitor battery levels, see Figure 3.11. The vicon 
bridge node gives the controlling station the positions and orientations of all the agents in 
the arena as well as the position and orientation of the operator. Once the UAVs are flying, 
the operator can start the custom AP node. Typically, either the way point force coefficient 


Side Number 

ROS namespace 

Wireless ID 

IP Address 

01 

Quadl 

ardrone 197467 

192.I68.0.10I 

02 

Quad2 

ardrone 198504 

192.I68.0.I02 

03 

Quad3 

ardrone 258674 

192.168.0.103 

04 

Quad4 

ardrone 256959 

192.168.0.104 

05 

Quads 

ardrone 266111 

192.168.0.105 

06 

Quad6 

ardrone 266678 

192.168.0.106 

07 

QuadV 

ardrone l 98307 

192.168.0.107 

08 

Quads 

ardrone_l 50853 

192.168.0.108 


Table 3.1: Identifiers for each AR.Drone in the swarm, from [41]. This table connects and 
identifies each drone with a hull number, ROS namespace identifier, SSID (Wireless ID), and IP 
number. 
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or the operator foree eoefficient are set to zero. This either plaees the experiment in operator 
follow mode or way point follow mode, respectively. 


3.3.2 Software Architecture 

Figure 3.10 shows the software architecture for agent tracking, receiving commands from 
the graphical user interface (GUI) and the hand-held controller, implemented on a Nintendo 
Wiimote (see Section 3.3.3), and sending commands to the agents. 



Figure 3.10: Simplified view of software architecture, for a more complete software architecture 
see (Appendix A 

) 


SwarmLoad.py 

SwarmLoad.py is an executable Python script that scans the Vicon server for connected 
AR.Drones. The script pings each drone’s network IP address based on the known IP ad¬ 
dress scheme, as defined in Table 3.1. If there is less than 100% packet loss (meaning 
positive communication with the drone is achieved), the script attempts to start an instance 
of the AR.Drone driver. SwarmLoad.py provides a set of parameters to each driver that 
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control: port addressing; video transmission rate; maximum altitude; minimum altitude; 
and altitude sonar pinger frequeney. The AR.Drone has two sonar pinger frequeneies avail¬ 
able. If multiple drones use the same frequency, then interferenee is likely, whieh results 
in altitude eontrol problems. Swarmload.py addresses this limitation by alternating the 
pinger frequeneies. For example drone one will operate using frequeney A, drone two will 
operate on frequeney B, but because there are only two frequeneies available, drone three 
will also operate on frequeney A. After starting an instanee of AR.Drone driver for eaeh 
eonneeted drone. Swarmload.py transmits a list of the drones using a ROS topie ealled 
DroneList. This topie informs the other nodes in the software arehiteeture how many and 
whieh AR.Drones are involved in the experiment. 

AP Algorithm 

At the eore of the software arehiteeture is the AP_Algorithm node. This node takes in tf 
referenee frame data from the wp_tf .broadcaster and drone.tf .broadcaster nodes. 
Using this data, the node ealeulates forees as outlined in Seetion 3.2. These forees are 
eonverted to veloeities whieh are published to each of the ardrone.driver nodes using 
the cmd.vel topie. 

Vicon 

The vicon.bridge node publishes to a topie for eaeh drone in the arena 
(vicon\ARSENLQUAD#\ARSENLQUAD# where # is the drone’s identifieation number) and to 
a topie assoeiated with the operator (vicon\diver\diver. These topies eontain position 
and orientation data. Position is given in the form of a translation veetor and orientation 
is represented by a quaternion. These data are eonverted into tf referenee frames by the 
drone.tf .broadcaster node. 

3.3.3 Human Swarm Robot Interaction 

A user also has basie takeoff, land, and emergeney reset eontrol of the drones via a eustom 
graphieal user interfaee (GUI), as illustrated in Figure 3.11. The push buttons are eonfig- 
ured to send Takeoff, Land, and Emergency Reset commands to the selected drones, 
indicated by checked boxes. For example, when the Takeoff button is pressed and ac¬ 
tivated, the GUI publishes a message to the Quad#\ardrone\takeoff (where # is the 
drone’s identification number) topics for each drone with a checked box. After the drones 
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takeoff, the Drone Status for eaeh drone ehanges from Landed to Flying based on in¬ 
formation reeeived from the Quad#\ardrone\navdata topics. In a similar fashion, the 
GUI receives battery charge information from the Quad#\ardrone\navdata topics and 
displays the percentages in the window. 


Swarm Master 


Takeoff 

Land 

Emergency 

1***1 jDrone Status! iBattery Level) 

^ droneO 

B dronel Landed 

B drone2 Landed 

B drones Landed 

B drone4 Landed 

drones 
droned 
drone? 
drones 
“ drones 

Figure 3.11: Custom GUI for basic group control of drones 


In order to give the human operator some basic control over the swarm, a Nintendo Wi- 
imote controller is integrated into the experiment. Wiimote controller state is monitored 
using the open source ROS wiimote package [45]. The Wiimote gives the operator the 
ability to collectively order swarm takeoff, landing, or emergency reset. It also gives the 
operator the ability to turn on and off the AP node by changing a ROS parameter used by 
the AP_Algorithm node. When the AP node is off, the drones go into hover mode. The 
“1” and “2” buttons respectively increase and decrease G, that is, the constant associated 
with the force felt by the drone due to the operator given in Equations 3.6 and 3.7. This 
interaction further allows the operator to heuristically tune and set this parameter. Eventu¬ 
ally, the Wiimote is envisioned to also give the operator the ability to take manual control 
of individual drones and fly them traditionally, as necessitated by the mission of interest. 
The current implementation of the Wiimote button mapping is shown in Eigure 3.12. 
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Takeoff / Land 




u- Move Forward 

Move Left 

I 


Move Right 

J AP Engine 

ON / OFF 

—1 * 

Move Backward 

Reset All 
Drones(hold 
for 1 sec) 


Reset Selected 

Drone 

Select Individual 

Drone 


O' 

Increase Operator Gain 


G 

Decrease Operator Gain 


Wii 



Figure 3.12: Nintendo Wiimote button mapping (manual control move left, right, forward, back¬ 
ward not yet implemented) 
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CHAPTER 4: 
Results 


4.1 Simulation 

We created two simulation environments to test and gain familiarity with our AP based 
framework. The first environment consists of a simple two-dimensional (2D) playing field 
with point particles. For the second, we used a 3D environment, with agent orientation 
taken into account, and used RVIZ to visualize in real time the creation of the swarm 
formation lattice. 


4.1.1 2D Simulations 

For the simple 2D simulation, we adapted a simulation program from Spears [15]. It con¬ 
sists of a simple 2D playing field with a set number of point particle agents where each 
is given an initial random positions. For simulation visualization we used the popular 
matplotlib library [46]. Each time step the agents move a set amount based on their 
proximity to all the other agents. After hundreds of time steps, the agents self organize into 
a lattice as seen in Figure 4.1 with four agents and in Figure 4.2 with 25 agents. 2D sim¬ 
ulation results were consistent with [15] which shows after thousands of time steps agents 
will create an organized hexagonal lattice (see Figure 4.3). 


4.1.2 3D Simulations 

We also created a more advanced three dimensional simulation using RVIZ for ROS [39]. 
In this simulation, the agents have orientation, and the forces are translated into the agent 
reference frames, see Figure 4.4. Once again, consistent with [15], the agents self-organize 
into a lattice after several thousand time steps. In the 3D simulation, there is no attempt to 
control drone altitude. All virtual forces and velocity commands are calculated in the xy 
plane so the lattice formation that appears is a 2D lattice similar to the results of the 2D 
simulations. We were able to later leverage this RVIZ code for real-time flight playback in 
RVIZ, which helped with troubleshooting the AP algorithm, see Figure 4.5. 
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Figure 4.1: Simple 2D simulation involving four agents 


4.1.3 Simulation Discussion 

These simulations validated the AP based framework and demonstrated that, given enough 
time steps, a group eonsisting of a few to many agents eould self-organize into a lattiee by 
responding to AP based virtual forees. One metrie for evaluating the performanee of the 
algorithm is the amount of time it takes for all agents to position themselves at the desired 
separation distanee from their neighbors. In the three dimensional RVIZ-based simulation, 
convergence typically took between two to three thousand time steps, or 20 to 30 sec, for 
the average separation distance between four agents to approach the desired separation 
distance of 1.25 m as seen in Figure 4.6. 

4.2 Physical Experimentation Results 

Our research group encountered multiple challenges during implemention of the frame¬ 
work on the actual AR.Drones. These challenges included networking, Vicon operating 
system compatibility issues, tf implementation problems, and drone altitude sonar pinger 
interference to name several hurdles. Eventually, we implemented the AP framework on 
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Figure 4.2: Simple 2D simulation involving 25 agents 
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Figure 4.3: Simple simulation run by Spears involving many agents and thousands of time steps, 
after [15] 


three drones alongside a human operator with a Wiimote eontroller, as shown in Figure 4.7. 
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Figure 4.4: Screen Capture of AP algorithm controlling four simulated drones using robot 3D 
visualization tool, RVIZ, for ROS 


4.2.1 AP Framework Drone Trajectories 

Figure 4.8(a) shows xy plane trajectories for a typical experimental run involving three 
drones and one human operator. In this run, the operator stayed as stationary as possible 
(operator translation < 4 cm as measured by Vicon) and the drones started several meters 
away in arbitrary positions and orientations relative to the operator. The coefficient associ¬ 
ated with way point attraction, B from Equation 3.8, was set to zero so that the drones were 
only affected by other drones and the operator. After 12 seconds, all drones are within 
20% separation error compared to desired separation from the operator which correlates 
to all drones being within 25 cm of their desired position, see Figure 4.8(b). Figure 4.9 
represents a snapshot of drone and operator positions with artificial force vectors superim¬ 
posed. These artificial force vectors represent the force vector summations for each drone. 
For example, the blue vector for drone 2 represents the summation of the following forces: 
attraction to the operator, attraction to drone 5, and attraction to drone 6 (as previously 
stated the parameter associated with way point attraction was set to zero so no attraction 
was felt toward the way point). Drone 2 is outside the desired separation distance to drone 
5, drone 6, and the operator. Because of this, its force vector points approximately towards 
the operator because of the relative positions of the drones and the higher force magnitude 
parameter associated with operator attraction. A similar explanation could be made for 
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Figure 4.5: Screen capture of flight data playback using RVIZ. The red sphere shows opera¬ 
tor location, red arrows indicate drone foward facing camera orientation, and the blue arrows 
represent the virtual force vectors. 


drone 5’s force vector. Drone 6 is within the desired separation distance of the operator 
which generates a strong repulsive force which is decreased due to drone 6’s attraction to 
drone 2 and 5. Section 4.2.2 goes into greater detail on how these artificial force vectors 
change over time for each drone. 

Figure 4.10(a) depicts the same run but several seconds later when the operator is walking 
in an approximately straight line. The drones are initially able to stay within 50% sep¬ 
aration error compared to desired separation from the operator which correlates to being 
within 63 cm of the desired position, but after the operator stopped the drones had difficulty 
regaining the correct separation distance, see Figure 4.10(b). One possible explanation for 
this is that we did not collect enough data and that given more time the drones would have 
formed a tighter formation. Unfortunately, at 22 sec into the run the operator started mov¬ 
ing again so the data does not exist to show that a tighter formation would have formed. It 
is also possible that system latency was higher during this part of the experiment and force 
calculations were being performed on position data that was not current. As discussed 
in Section 4.2.3, this experimental setup warranted further study of how operator position 
perturbations affect the drones’ ability to reform into a lattice formation. 
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Time (sec) 

Figure 4.6: Average separation versus time with four drones for 3D RVIZ simulation (Desired 
Separation = 1.25, G = 2700, w = \.0, p = 2.0, At = 0.01) 


4.2.2 Artificial Force Vector Evolution 

To further illustrate how the foree veetors evolve over time, Figure 4.11 depiets drone 
position with drone foree veetors superimposed over a six seeond time period. During 
this time period, the drone start in arbitrary positions, but after six seeonds end up in an 
approximate lattiee shape. After six seeonds, the foree veetor magnitudes are mueh smaller 
than at the beginning of the experiment. This is beeause the repulsive and attraetive forees 
are summing to a number near zero. Having a foree veetor magnitude near zero when in 
tight formation is desirable, beeause it minimizes the amplitude of oseillations, thereby 
deereasing the probability of a eollision. Note that beeause of the differenee between the 
parameters C and G, the veetors may not appear to have the eorreet direetion or magnitude. 
We re-eheeked our results by having the AP algorithm output intermediate results to the 
operator’s eonsole, whieh we eompared to hand ealeulations performed using raw data from 
Vieon. Our manual ealeulations were eonsistent with the intermediate and final results. 
This demonstrates that the AP algorithm was eorreetly implemented and that there were 
not eode problems involving referenee frame transformations or foree ealeulations. If we 
had pieked different foree parameters, the magnitudes and direetions of the resultant foree 
veetors would be different. 

The operator was able to walk around the Vieon spaee while the drones followed and re¬ 
formed a lattiee shape around the operator when he stopped. Lateney in the system and 
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Operator with IR reflector helmet and 
Wiimote controller 


Three quadrotors, using artificial physics 
engine for motion control 


Figure 4.7: Human operator wearing Vicon marker helmet controlling three agents using Wiimote 
hand-held controller 


imposed velocity constraints made it so the operator could escape the formation center by 
walking briskly. We also conducted experiments without the operator where the drones 
were given a set of way points to navigate but did not perform rigorous data collection on 
these experiments. Initial observations showed that when the a new way point was inserted, 
the drone would break formation, travel to the new way point, and recreate a lattice for¬ 
mation. We need to collect data from these way point experiments as further discussed in 
Chapter 5. 


4.2.3 Additional Experiments 

We ran additional experiments to examine the amount of time required after an operator 
position perturbation for the drones to regain desired separation. Figure 4.12 depicts the 
results of this experiment, and Figure 4.13 shows time-lapse photographs of the operator’s 
position relative to the drones. The operator took a brisk one meter step in the x-direction, 
stayed stationary for seven seconds, and then took a brisk step to return himself to his 
original position. Error in average separation distance grew during and after the initial step 
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input displacement, but returned to within 25% of the desired separation distanee after the 
perturbation was over. This experimental run exhibited a higher error in error in desired 
separation distanee eompared to the run deseribed in Seetion 4.2.1. Again, this may be 
attributable to system lateney inereasing with time. It eould also be due to slightly larger 
operator position perturbations when the operator was trying to stand still (10 em vs. 4 em 
as measured by Vieon). 

4.2.4 Physical Results Discussion 

Our framework was effeetive at autonomously organizing a group of AR.Drones in arbi¬ 
trary starting positions and orientations around a human operator. The drones were fairly 
eonsistent in finding the operator and ereating a formation. Even with a moving operator, 
the drones would follow and reform into a formation after the operator stopped. Despite 
these initial positive results, drone on drone eollisions were not uneommon. It appears that 
lateney in the system sometimes allows drones to get too elose to eaeh other. Once the 
drones are within approximately 0.5 m of eaeh other, rotor blade wash frequently eauses 
instability. Sometimes the drones reeover, but other times the wash leads to a eollision and 
one or both drones erash into the ground. AR.Drones are built with the home hobbyist in 
mind and are built to withstand multiple erashes. We frequently had to glue baek on the 
Vieon eonstellation marker balls due to them falling off after a erash. 
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(a) xy trajectories for three drones with stationary operator 


Drone Distance from Stationary Operator 


— Drone2 — DroneS Drone6 — Desired Separation 



°0 2 4 6 8 10 12 14 16 

t(s) 

(b) Average separation distance from operator over time with stationary operator 

Figure 4.8: Experimental results for three drones with a stationary operator (Desired Separation 
= 1.25 m, way point parameter B = 0, agent to agent parameter C = 2.2, agent to operator 
parameter G = 3.1, distance exponent parameter p = 2.0, time duration per time step At = 0.03 

s) 
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Figure 4.9: Drone and operator positions with artificial force vectors 
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(a) xy trajectories for three drones with moving operator 


Drone Distance from Stationary Operator 


— Drone2 — DroneS Drone6 — Desired Separation 



. Operator Moving 

Operator Stationary .. 
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(b) Average separation distance from operator over time with initially moving then 
stationary operator 

Figure 4.10: Experimental results for three drones with an initially moving then stationary opera¬ 
tor (Desired Separation = 1.25 m, way point parameter B = 0, agent to agent parameter C = 2.2, 
agent to operator parameter G = 3.1, distance exponent parameter p = 2.0, time duration per 
time step Af = 0.03 s) 37 









































Force Vector Evolution 
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Figure 4.11: Evolution of Force Vectors over a six second time period with stationary operator. 
Overtime, force vectors change direction and magnitude as the geometry of the experiment 
changes. After the six seconds shown, the drones are in a stable formation with separation 
distances from the operator within 20% of the desired value (Desired Separation = 1.25 m, 
B = 0, C = 3.2, G = 2.2, p = 2.0, At = 0.03 s) 
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Operator (x.y) position 



t(s) 



Figure 4.12: Graphs show operator discpiacement in the a: and y directions as a function of time. 
In this experiment, the operator took a one m step in the positive;*: direction, stood still for sevon 
sec, and took a step in the negative x direction to return to the origin. During the experiment, 
average drone to operator separation was plotted as function of time. While the operator is 
moving, average separation distance increases as the drones attempt to recreate the formation. 
After the operator returns to the origin and stops moving, average separation distance approaches 
the desired separation distance as the formation is recreated (Desired Separation = 1.25 m, B = 0, 
C = 3.2, G = 2.2, p = 2.0, At = 0.03 s). 
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(a) t = 10 sec 



(b) t = 14 sec 



(c) t = 18 sec 




Figure 4.13: Operator and drone photographs for numerical results depicted in Figure 4.12. As 
the operator took a step forward the drones followed and attempted to recreate a formation. 
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CHAPTER 5: 

Conclusion and Future Work 


5.1 Conclusion 

We validated our framework using both 2D and 3D simulations and successfully applied it 
to a group of drones which allowed them to follow a human operator inside an instrumented 
space. Other than initiating their collective launch with a takeoff command to the drones, 
no further human input was required for the drones to find and follow the operator, based 
on data from the indoor motion capture system. Experimental results showed that after 
operator movement, it would typically take between five to ten sec for the drones to form 
into a stable formation. A hand-held controller gave the operator the ability to takeoff and 
land the drones, as well as to change the coefficients associated with drone to operator 
attraction or repulsion forces. 

In addition to the development and demonstration of the presented artificial physics-based 
framework, the following items highlight various contributions accomplished in this thesis: 

• Development of real-time simulations in 2D and 3D environments 

• Design and software implementation of SwarmLoad. py utility for automation of 
AR.Drone driver loading for multiple drones on the GCS computer 

• Design and development of a dashboard GUI for basic AR.Drone group control and 
monitoring 

• Testing and development of code for Wiimote hand-held controller integration 

• Closed-loop integration and documentation of motion capture system with Robot 
Operating System-based software architecture 

• Experimental dataset generation of multi-drone flight data for further playback and 
analysis 

As noted in Chapter 2, there has been little prior research involving multiple UAV intention¬ 
ally operating in close proximity to a human operator, although there is increasing interest 
in this topic. This thesis offers a possible approach for allowing humans and UAVs to safely 
work together in a constrained environment. 
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5.2 Recommendations 

Given this emerging area of researeh, there are numerous avenues for immediate aetiv- 
ities that will enhanee further near-term developments for studying interaetions between 
multiple drones and their operator(s). 

5.2.1 Definition of Relevant Performance Metrics 

This work highlighted the need to develop more rigorous metries of performanee for swarm 
behaviors. Traeking deviation from desired separation distanee from the operator is only 
suffieient for assessment of a small numbers of drones. For example, if there are more 
than six drones, due to the nature of hexagonal lattiees, there will be one drone between 
the seventh drone and the operator. This means that by nature of the AP algorithm, not all 
drones may be able to approaeh the desired separation distanee from the operator. However, 
all drones should be able to reaeh the desired separation distanee from all other drones. 

As diseussed by Spears [15], one method for evaluating formation quality is to average the 
error in the expeeted angle between agents within the formation lattiee. This method would 
have to be modified for our purposes due to the possible differenees in the eonstants C and 
G. One would have to do a foree balanee problem to ealeulate what the theoretieal angles 
should be. This proeess eould be automated and eompared to physieal experimental data. 

Further, one is left asking if a five-to-ten seeond interval is good or bad amount of time 
for three drones to loeate and eonverge on the operator, whieh likely will depend on the 
operator interaetion neeessary for a given mission or applieation. Spears does not address 
the time required to form the lattiee into eonsideration as a performanee metrie. However, 
for our purposes, due to praetieal eonsiderations sueh as battery life and a dynamieally 
moving operator, eonvergenee time to get into position is important. As sueh, future metries 
need to take into aeeount both time and lattiee quality. Additional eharaeterizations of 
swarm performanee are likely to yield new researeh direetions as well, as swarm algorithms 
are developed to address these objeetives. 

5.2.2 Additional Experiments 

There are many follow-on experiments that would illuminate additional insights. One near- 
term experiment to be eondueted should inelude one in whieh the eoeffieients assoeiated 
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with drone-to-drone force and drone-to-operator force, G and C from Equation 3.4 and 
Equation 3.6, respectively, are varied incrementally to find the set of coefficients that min¬ 
imize collisions and time required to find and create a formation around the operator. In¬ 
crementally changing the desired separation distance should also be explored. Another 
potential experiment that warrants data collection and analysis is an experiment designed 
to further test the way point attraction that is already built into the AP algorithm. Data 
should be collected both with an operator present and without an operator present. Addi¬ 
tional functionality should be added that allows the drones to follow way points and avoid 
collision with the operator without attraction to the operator like under normal operation. 

5.2.3 Continued Hand-held Controller and GUI Integration 

The Wiimote is a good basic hand-held controller for basic drone group control. However, 
for more sophisticated interactions, its functionality should be extended to include a critical 
assessment of usability, i.e., what are the most useful button mappings. Specifically, further 
enhancements are required to the code that allows the user to take manual control of drones 
one at a time. Such modifications would reduce the amount of time required to set up trials 
and could lead to more interesting experiments where some drones are acting autonomously 
and some are under manual control. Another extension includes improving the GUI to have 
additional functionality such as point-and-click manual drone control, way point setting, 
and control over the constants used to calculate virtual force magnitudes. RVIZ is a good 
candidate for point-and-click manual control and way point setting. There exist built-in 
software libraries that allow for interactive markers in RVIZ, such that, e.g., a mouse click 
on a RVIZ screen could be translated into a command to move to a new position. 

5.2.4 Altitude Control Issue Resolution 

As previously discussed when multiple AR.Drones are in close proximity, there are fre¬ 
quent, sometime large (> 4 m), altitude excursions. We hypothesize that these excursions 
are due to pinger interference from the ultrasonic range sensing altimeter. Eurther experi¬ 
ments need to be conducted to verify this hypothesis and characterize this interference. If 
this is indeed the source of the problem, we need to examine if there is a software solution. 
This could require attempting modifications to the AR.Drone 1.0 firmware and altering the 
inner-loop altitude control feedback loop. Ideally, for indoor flight, altitude control feed¬ 
back could come solely from Vicon, but would require software setting modifications to 
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enable eircumventing the built-in altimeter. 


5.2.5 Integration of AR.Drone 2.0 

We colleeted all of our data using the AR Drone 1.0. Additional experiments should uti¬ 
lize the Advanced Robotic Systems Engineering Laboratory (ARSENL) AR Drone 2.0 
fleet. Switching platforms may help with inner-loop altitude control issues and would al¬ 
low longer flight times. The 2.0 Power Edition drones come with 1600 mAh batteries and 
can operate for approximately 18 minutes [35]. Longer flight times would greatly decrease 
the amount of time required to run repeated experiments and could enable the performance 
of more complicated mission based testing. 

A laptop running Ubuntu 12.04 LTS with an Intel Core i5 processor and 1.9 GB of RAM 
was the main computer used for drone control and data logging. Upgrading to a more 
powerful machine could enable running experiments with more than three drones. Using 
several computers to comprise the GCS could also increase our ability to fly more drones 
simultaneously by splitting up processing tasks between the machines. We could connect 
these machines via a ROS network [47]. A ROS network allows multiple machines to 
share access to the same ROS topics. Eor example, one computer would be responsible for 
ingesting Vicon data and doing tf reference frame transformations. A second computer 
would use these transformations to calculate and transmit velocity commands to the drones. 

5.2.6 Exception Handling 

As currently coded, the AP node is not very robust. There is little or no logic for handling 
situations, for example, where an agent or operator leaves the Vicon coverage area. When 
this happens, the program currently fails and the drones continue to execute the last received 
command, which is usually not desirable. Of general applicability, there exists a need to 
develop code to command the drones back into the arena when they cross the boundary of 
the Vicon coverage area. One possible way to accomplish this is through dead reckoning. 
Dead reckoning could be used to estimate the drones position and orientation based on its 
received velocity commands and last good Vicon position and orientation measurement. 
Using the dead reckoned position, an algorithm could send new velocity commands to the 
agent to bring it back into Vicon coverage. Dead reckoned position would also update the 
AP node and could be used for calculating forces for other agents. 
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5.3 Future Work 

5.3.1 Outdoor Flight 

Currently, the Federal Aviation Administration (FAA), for civilian aircraft, and Naval 
Air Systems Command (NAVAIR), for Navy-owned platforms, place restrictions on UAV 
testing for research and development purposes. As of the publication of this thesis, the 
AR.Drone is not cleared for outdoor flight testing by Navy institutions. Assuming the 
AR.Drone does eventually receive an interim flight clearance, the next step in our research 
is to take the drones outside of the Vicon space and run the same experiments using GPS in a 
controlled outdoor environment. Parrot produces a GPS receiver for the AR.Drone 2.0 (see 
Figure 5.1). Note, however, that GPS is not yet implemented in the ardrone_autonomy 
ROS package. Future outdoor research would necessitate adapting this package to process 
and transmit GPS information via the WiFi connection. Taking the experiments outdoors 
would afford us the space to test the AP framework using more agents. 



Figure 5.1: The Parrot Flight Recorder for the AR.Drone 2.0 has an on-board GPS, from [48]. 

5.3.2 Adding More Agents 

Our research usually involves three or fewer AR.Drones with one human operator. Ex¬ 
ceeding three agents with one controlling station appeared to result in too much latency 
for a satisfactory level of control. It is unclear if the latency is due to network bandwidth, 
controlling station processing limitations, tf algorithm limitations, or the Vicon motion 
capturing system. Using a controlling station with more processing power in conjunction 
with running a network packet monitoring program such as Wireshark could help identify 
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the bottleneck. As discussed in Section 3.3.2, sonar pinger interference is another major 
limiting factor in piloting multiple AR.Drones in a small arena. It may be necessary to 
modify the drone’s firmware to remove pinger data from the altitude control algorithms. 

5.3.3 Tag Detection and Computer Vision 

The AR.Drone 1.0 is equipped with two cameras. Using its own onboard processing power, 
the drone is able to detect the presence and relative position of special colored tags. The raw 
drone video feed can also be analyzed using tools like OpenCV to perform tasks such as 
localization, collision prevention, and threat detection. Future research should leverage the 
existing hardware on the drones and incorporate open source programs such as OpenCV. 
Incorporating tag detection and computer vision will help enable mission-based testing. 

5.3.4 Mission-Based Testing 

Part of the motivation for this project was to show that a group of drones could be useful 
in the field for following a group of operators and alerting them to threats. We need to 
design experiments that allow us to work up to this goal. Such experiments will leverage 
the drone’s camera sensors and will need to be conducted outdoors due to space constraints 
in the existing NPS Vicon space. The computer or computers that comprise the GCS should 
be further designed so that an operator could carry them in a backpack. 
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APPENDIX A: 

ROS Software Architecture 



ROS node connection graph generated using rqt.graph [49] 
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